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DEVICES, SOFTWARES AND METHODS FOR RULE BASED 
4 DETERMINATION OF ATTRIBUTES OF CALLED DEVICE FOR 

NETWORK TELEPHONE CALL SETUP 

BACKGROUND OF THE INVENTION 

8 1 . Field of the invention. 

The present invention is related to the field of network telephony, and more 
specifically to devices, softwares and methods for accelerating the setup of a network 
telephone call. 

12 

2. Description of the related art. 

Networks such as the internet are increasingly used for telephony. Prior to 

actually speaking on the telephone, the end devices are engaged in setting up the 
1 6 telephone call. The process of setting up takes place by exchanging signals, as 

dictated by an appropriate protocol. 

More generally, a number of applications run above the Internet Protocol (IP) 

layer. Such applications include multimedia applications, as for example Voice over 
20 IP (V oIP). Network telephony takes place under VoIP . 

Each telephone call is made by two complementary voice streams between the 

two end devices. Admission control for such applications is supported through the 

use of RSVP signaling and RSVP admission control. For example, setting up the call 
24 could involve setting up two RSVP sessions, i.e., one RSVP session for each of the 

two voice streams. "RSVP" stands for "Resource Reservation Protocol", and is also 

known as "Resource Reservation Setup Protocol". It is a protocol that supports the 

reservation of resources across an IP network. Applications running on IP end 
28 systems can use RSVP to indicate to other nodes the specification of the packet 

streams they want to receive. The specification involves bandwidth, jitter, maximum 

burst, port number, and so forth of the packets. 

RSVP signaling takes place during application session establishment, which in 
32 the case of VoIP is during call setup. RSVP signaling must be synchronized with the 

application session establishment phase, which in the case of VoIP is with Voice 
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signaling call flow. This is necessary to ensure compatible behavior from the end 
user. 

This must take place fast. In the case of VoIP, RSVP signaling must happen 
4 early enough in the VoIP signaling call flow, so that RSVP admission control can take 
place before the telephone of the called party rings. To constrain matters even more, 
since RSVP is unidirectional, it must be initiated by each one of the two parties to the 
prospective exchange. But RSVP signaling can only take place once sufficient 
8 information about the session is known to each side about the other. 

Two examples of this type of information that needs to become known are 
now discussed. 

First, in the particular case of the International Telecommunications Standard 
12 (ITU) as H.323 version 3, section ITU-T SG16 specifies one approach for 

synchronizing RSVP signaling with H.323 signaling. This approach has the purpose 
of, among others, negotiating the required level of Quality of Service (QoS). For this 
purpose, the called party is required to convey to the calling party some information 
1 6 before the caller can initiate RSVP signaling. The information is conveyed through 
H.323 signaling messages, and relates to a number of attributes for the session 
associated by the called party. 

The H.323 signaling messages have at least two fields. A first field is 
20 sometimes called QoScapabilities, and includes the bandwidth, the burst size, etc. A 
second field is sometimes called OpenLogicalChannel field, and includes a subfield 
called the H2250LogicalChannelParameters. The latter includes the port numbers 
used. 

24 Referring to Fig. 1 , a signaling sequence 100 shows salient portions of ITU 

Standard H.323. Sequence 100 may be used for exchanging messages (also known as 
signals) that contain such information. 

In Fig. 1, an originating device OD calls a terminating device TD by sending a 
28 message 110. Messag& 1 1 0 is also known as Q.93 1 Setup with fastStart. 

Terminating Device TD then responds with messages 120 and 130. Message 
120 is also known as Q.931 CallProceeding with fastStart, and includes information 
as to how device TD is to be accessed. Message 130 is also known as RSVP Path, 
32 and includes information as to how device TD will be accessing. 

Originating Device OD then has enough information to initiate the RSVP 
session. Device OD then responds with messages 140 and 150. Message 140 is also 
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known as an RSVP Resv (reservation) signal. Message 150 is also known as RSVP 
Path, and is reciprocal to message 130. 

The second example is with the relatively new, so-called Session Initiation 

4 Protocol (SIP). Under SIP there is a QoS precondition establishment, where the 
called party has to convey information to the calling party. This is conveyed by an 
SIP signaling message under 183 Session Progress. The message includes an SDP 
which contains information on the session attributes necessary for the calling party to 
8 initiate the RSVP session with the called party. 

A complexity is with the H.323 CallProceeding message and the equivalent 
SIP 183 message. They are both optional and many vendors might not implement 
them in the first place. Because they constitute additional steps in the call flow and 

12 thus increase call establishment time, these signaling messages may need to be 

avoided in some environments which require very fast call establishment. Yet other 
application protocols might not include at all an equivalent of the CallProceeding 
message. Then the attributes do not become known, or other arrangements are 

16 necessary. 

BRIEF SUMMARY OF THE INVENTION 

The present invention overcomes these problems and limitations of the prior 

20 art. 

Generally, the present invention provides devices, softwares and methods that 
can establish an IP connection with each other through a network. According to the 
invention, dynamic connection attributes of the called device are inferred locally by 

24 the calling device. These may include any one or more of type of codec, bandwidth, 
port number, and so on. 

The invention offers the advantage that call setup is thus faster. This is 
because the calling device need not wait to receive this information explicitly by 

28 signaling. Even more, an advantageous call setup may take place even between 

devices, applications and protocols do not include a H.323 CallProceeding message or 
its equivalent. 

The invention will become more readily apparent from the following Detailed 
32 Description, which proceeds with reference to the drawings, in which: 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a prior art signaling sequence of devices setting up a network 
connection between them. 
4 Fig. 2 is a diagram of two devices made according to embodiments of the 

invention, and setting up a network connection between them according to an 
embodiment of the invention. 

Fig. 3 is a flowchart illustrating a method according to an embodiment of the 
8 present invention. 

Fig. 4 is a flowchart illustrating a method according to another embodiment of 
the present invention. 

Fig. 5 is a signaling sequence according to an embodiment of the invention for 
1 2 synchronizing a H.323 fastStart signaling with RS VP signaling. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT(S) 

As has been mentioned, the present invention provides devices, softwares and 
1 6 methods that can establish an IP connection with each other. The invention is now 

described in more detail. 

Referring now to Fig. 2, a network 210 separates devices 220, 240 which are 

made according to embodiments of the invention. These devices may establish a 
20 network connection 250. For the example of Fig. 2, device 220 is the calling device, 

which is also known as the originating device, because it is the device that originates 

the telephone call. Equally, device 240 is the called device, which is also called the 

terminating device, because it is the device where the telephone call terminates. 
24 Devices 220, 240 may be any type of network switch that can accommodate 

VoIP and other applications that run above the IP layer. For example, devices 220, 

240 may be voice gateways or end devices, such as IP telephones. 

Switch 220 has a network interface 222, and switch 240 has a network 
28 interface 242. Interfaces 222, 242 are for interfacing with a network, such as network 

210. 

Switch 220 also has a processor 224 coupled with network interface 222. 
Switch 240 has a processor 244 coupled with network interface 242. Processors 224, 
32 244 may be implemented as a Digital Signal Processors (DSPs), Central Processing 
Units (CPUs), or any other equivalent way known in the art. 
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Switch 220 additionally includes a memory 228, on which a program 229 may 
reside. Functions of processor 224 may be controlled by program 229, as will become 
apparent from the below. 

4 Switch 240 moreover includes a memory 248, on which a program 249 may 

reside. Functions of processor 244 may be controlled by program 249, as will become 
apparent from the below. 

The present invention may be implemented by one or more devices that 
8 include logic circuitry. The device performs functions and/or methods as are 

described in this document. The logic circuitry may include a processor that may be 
programmable for a general purpose, or dedicated, such as microcontroller, a 
microprocessor, a Digital Signal Processor (DSP), etc. For example, the device may 

12 be a digital computer like device, such as a general-purpose computer selectively 
activated or reconfigured by a computer program stored in the computer. 

Moreover, the invention additionally provides methods, which are described 
below. The methods and algorithms presented herein are not necessarily inherently 

1 6 associated with any particular computer or other apparatus. Rather, various general- 
purpose machines may be used with programs in accordance with the teachings 
herein, or it may prove more convenient to construct more specialized apparatus to 
perform the required method steps. The required structure for a variety of these 

20 machines will become apparent from this description. 

In all cases there should be borne in mind the distinction between the method 
of the invention itself and the method of operating a computing machine. The present 
invention relates both to methods in general, and also to steps for operating a 

24 computer and for processing electrical or other physical signals to generate other 
desired physical signals. 

The invention additionally provides programs, and methods of operation of the 
programs. A program is generally defined as a group of steps leading to a desired 

28 result, due to their nature and their sequence. A program made according to an 

embodiment of the invention is most advantageously implemented as a program for a 
computing machine, such as a general-purpose computer, a special purpose computer, 
a microprocessor, etc. 

32 The invention also provides storage media that, individually or in combination 

with others, have stored thereon instructions of a program made according to the 
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invention. A storage medium according to the invention is a computer-readable 
medium, such as a memory, and is read by the computing machine mentioned above. 
The steps or instructions of a program made according to an embodiment of 
4 the invention requires physical manipulations of physical quantities. Usually, though 
not necessarily, these quantities may be transferred, combined, compared, and 
otherwise manipulated or processed according to the instructions, and they may also 
be stored in a computer-readable medium. These quantities include, for example 
8 electrical, magnetic, and electromagnetic signals, and also states of matter that can be 
queried by such signals. It is convenient at times, principally for reasons of common 
usage, to refer to these quantities as bits, data bits, samples, values, symbols, 
characters, images, terms, numbers, or the like. It should be borne in mind, however, 
12 that all of these and similar terms are associated with the appropriate physical 

quantities, and that these terms are merely convenient labels applied to these physical 
quantities, individually or in groups. 

This detailed description is presented largely in terms of flowcharts, display 
1 6 images, algorithms, and symbolic representations of operations of data bits within at 
least one computer readable medium, such as a memory. An economy is achieved in 
the present document in that a single set of flowcharts is used to describe both 
methods of the invention, and programs according to the invention. Indeed, such 
20 descriptions and representations are the type of convenient labels used by those 
skilled in programming and/or the data processing arts to effectively convey the 
substance of their work to others skilled in the art. A person skilled in the art of 
programming may use these descriptions to readily generate specific instructions for 
24 implementing a program according to the present invention. 

Often, for the sake of convenience only, it is preferred to implement and 
describe a program as various interconnected distinct software modules or features, 
individually and collectively also known as software and softwares. This is not 
28 necessary, however, and there may be cases where modules are equivalently 

aggregated into a single program with unclear boundaries. In any event, the software 
modules or features of the present invention may be implemented by themselves, or in 
combination with others. Even though it is said that the program may be stored in a 
32 computer-readable medium, it should be clear to a person skilled in the art that it need 
not be a single memory, or even a single machine. Various portions, modules or 
features of it may reside in separate memories, or even separate machines. The 
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separate machines may be connected directly, or through a network, such as a local 
access network (LAN), or a global network, such as the Internet. 

In the present case, methods of the invention are implemented by machine 
4 operations. In other words, embodiments of programs of the invention are made such 
that they perform methods of the invention that are described in this document. These 
may be optionally performed in conjunction with one or more human operators 
performing some, but not all of them. As per the above, the users need not be 
8 collocated with each other, but each only with a machine that houses a portion of the 
program. Alternately, some of these machines may operate automatically, without 
users and/or independently from each other. 

Continuing to refer to Fig. 2, connection 250 is set up according to the 
1 2 invention. That is, at least one dynamic attribute of the terminating device is inferred 
by the originating device, instead of being learned explicitly by a received signal. 

Inferring is based on rules, which may even become protocols. The invention 
will not work if the devices do not follow the same rule. Sensible rules are preferably 
1 6 chosen, which increases the likelihood that there will be a match of the rules, and that 
therefore the invention will work. 

Methods of the invention are now described. 

Referring now to Fig. 3, a flowchart 300 is used to illustrate a method 
20 according to an embodiment of the invention. The method of flowchart 300 may also 
be practiced by a calling device, such as device 220 of Fig. 2. 

According to a box 310, a call setup message is transmitted to another device, 
such as to device 240 of Fig. 2. The call setup message may be an H.323 version 3 
24 fastStart type message, although that is not necessary for practicing the invention. 

According to a next box 320, a reply message is received from the other 
device. The reply message is received in response to the call setup message. 

According to a next box 330, the reply message is analyzed. Its content 
28 therefore becomes known. The reply message may include an identifying number of 
a port that the other device will be using to transmit data from. The reply message 
may be an RSVP Path type message, although that is not necessary for practicing the 
invention. 

32 According to a next box 340, it is determined from analyzing the reply 

message that at least some of the information is not included in the reply message, and 
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moreover it is decided that the missing information will not be forthcoming. That 
information is about a dynamic attribute of the device for the connection session. 
Deciding may be performed by determining that the reply message was 
4 received before information about the attribute was received, even though a protocol 
might dictate so. For example, if the reply message is an RSVP Path type message, it 
should have been received after a Q.931 CallProceeding message 120, as per the 
protocol of Fig. 1 . But since that did not happen, it may be decided that message 120 
8 will not be coming at all. In this case, the missing information includes which port 
the other device will use to receive data from. 

Deciding that the information will not be forthcoming is advantageously 
interpreted according to the invention as an invitation to a faster connection. 
12 According to a next box 350, the attribute of the device is inferred. Inferring 

is based on a rule, assuming the other device uses the same rule. This corresponds to 
accepting the invitation. 

Any one or more attributes may be inferred according to the invention. For 
1 6 example, the inferred attribute is a codec type of the device. Or the inferred attribute 
is a maximum bandwidth that the device may receive data in. 

In the case where message 1 20 is missing, the inferred attribute may be about 
the port number that will be used by the device to receive data from. For example, if 
20 the reply message includes an identifying number of a port that the device will be 

using to transmit data from, and the inferred attribute may be the port number that will 
be used by the device to receive data from. It may be inferred as a function of the 
identified port number, for example either the same port, or one derived by a preset 
24 operation. An example of such a preset operation may be to add a preset number (e.g. 
the number 2) to the identified port number. 

According to a next box 360, data is transmitted to the other device, using the 
inferred attribute. The data may be audio packets, once the connection is established. 
28 For example, the audio packets may be addressed to the number of the port of the 
other device that was inferred to receive data. 

It will be appreciated by a person skilled in the art that there are more steps 
between box 350 and box 360, and also possibly between other boxes. These are not 
32 repeated here so as not to obscure unnecessarily the present description. 
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Referring now to Fig. 4, a flowchart 400 is used to illustrate a method 
according to another embodiment of the invention. The method of flowchart 400 may 
also be practiced by a called device, such as device 240 of Fig. 2. 

According to a box 410, a call setup message is received from another device, 
such as device 220 of Fig. 2. The call setup message may be an H.323 version 3 
fastStart type message, although that is not necessary for practicing the invention. 

According to a next box 420, a single one of the ports is configured to transmit 
data through, and also to receive data from. 

According to a next box 430, a reply message may be transmitted to the other 
device. The reply message need only identify the port as a port to transmit data 
through. According to the invention, the reply message need not also identify the port 
as a port to receive data from. This is performed in the hope that the other device will 
infer, by using the suggested rule that the same port be used for transmitting and 
receiving. In that way, the abbreviated reply is an invitation to the calling device for a 
faster connection. 

As an example, if the call setup message is an H.323 version 3 fastStart type 
message, the reply message may simply be an RSVP Path type message. As a result, 
no different type of signaling will be necessitated to implement the invention. 

According to a next box 440, data is received, such as audio packets. The 
received data is addressed to the single port in response to the reply message. That is 
because the other device has made the desired inference. 

It will be appreciated that the invention may be practiced with any number of 
connection protocols that work for an RSVP session, or a session equivalent to an 
RSVP session. In other words, the invention is not limited to the H.323 and SIP 
protocols that are described herein. 

In both cases, the invention may be implemented by leveraging the 
RSVP/application API extensions. Another advantage of this invention is that it does 
not require that the standard signaling protocols be changed. The RSVP API must 
support the following functions: 

Path Listen: an application can listen to incoming Path events for a given 
session (a session is identified by destination IP address, destination port, and protocol 
ID). The API should provide the application with information about the sender 
(sender IP address and sender port). 
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Resv Listen: an application can listen to incoming Resv events for a given 
session. 

In addition, the API should enable the application to listen to ResvConf and 
4 ResvErr events for a given session. 

It will be appreciated by a person skilled in the art that there are more steps 
between box 430 and box 440, and also possibly elsewhere in this description. These 
are not repeated here so as not to obscure unnecessarily the present description. 
8 Referring now to Fig. 5, an example of a signaling sequence is given for the 

arrangement of Fig. 2, using H.323 signaling. Elements of the sequence have already 
been described in connection with Fig. 3 and Fig. 4. The person skilled in the art will 
appreciate that the signaling will be similar for other protocols, such as SIP. 
12 Initially, device OD only knows its own IP address and UDP voice port for 

the call being established. It starts listening for RSVP messages for the session. It 
does that with (dest. IP = OD, dest. Port = OD's UDP port, protocol ID = UDP). By 
"dest." it is meant "destination". 
16 Then device OD sends Q.931 Setup message 510 to device TD. It includes its 

IP address and UDP port number in the fastStart field. This message 510 may be the 
same as message 110 of Fig. 1. 

Then, device TD receives the Setup message from device OD. Device TD 
20 thus learns the OD's IP address and port number. 

Then according to box 515, device TD applies the rules to assign a UDP port 
for this call. It now has all the information necessary to start the RSVP signaling. 
The port will be for both transmitting and receiving data. 
24 Then device TD starts listening for RSVP messages for the session. It listens 

for messages with (dest. IP = TD, dest. Port = TD's UDP port, protocol ID = UDP). 

Then device TD sends to the OD an RSVP Path message 530 for the stream 
from TD to OD, i.e. the session with (dest. IP = OD, dest. Port = OD's UDP port, 
28 protocol ID = UDP). 

Then device OD receives the Path message 530. From the Path message, it 
learns TD IP address and UDP port number. 

Then according to box 535, device OD infers that device TD will be using the 
32 same port for both transmitting and receiving data. 

Then device OD sends a RSVP Resv message 540 in response to the received 
RSVP Path message 530. It can also send a Path message 550 for the stream from 
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OD to TD, i.e. the session (dest. IP = TD, dest. Port = TD's UDP port, protocol ID = 

UDP). This is received by device TD. 

To complete the handshake, device TD responds by sending a Resv request for 
4 the stream from OD to TD. Then device TD also receives the Resv message for the 

stream from TD to OD. The reservation for the stream from TD to OD is now 

complete. An RSVP RevConf message may be this sent in response to the received 

Resv message, but this is optional. 
8 Then device OD receives the Resv message for the stream from OD to TD. 

The reservation for the stream from OD to TD is now complete. Then device OD 

must send a ResvConf message to TD. 

When device TD receives the ResvConf, if it has already received the Rev 
12 message for TD to OD, it knows the reservation process has been completed for 

streams in both directions. The Q.931 call setup signaling can resume. 

A person skilled in the art will be able to practice the present invention in view 

of the description present in this document, which is to be taken as a whole. 
1 6 Numerous details have been set forth in order to provide a more thorough 

understanding of the invention. In other instances, well-known features have not been 

described in detail in order not to obscure unnecessarily the invention. 

While the invention has been disclosed in its preferred form, the specific 
20 embodiments as disclosed and illustrated herein are not to be considered in a limiting 

sense. Indeed, it should be readily apparent to those skilled in the art in view of the 

present description that the invention may be modified in numerous ways. The 

inventor regards the subject matter of the invention to include all combinations and 
24 subcombinations of the various elements, features, functions and/or properties 

disclosed herein. 

The following claims define certain combinations and subcombinations, which 
are regarded as novel and non-obvious. Additional claims for other combinations and 
28 subcombinations of features, functions, elements and/or properties may be presented 
in this or a related document. 
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